home *** CD-ROM | disk | FTP | other *** search
/ MacFormat 1995 January / macformat-020.iso / Shareware City / Developers / apps.to.go / Kibitz / !! Kibitz.Theory < prev    next >
Encoding:
Text File  |  1994-05-06  |  3.1 KB  |  57 lines  |  [TEXT/MPS ]
  1. The area that needs most explaining in Kibitz is the AppleEvents stuff.  This
  2. turned out to be trickier than I had thought it would be.  It wasn't creating
  3. or sending the AppleEvents that was difficult.  This turned out to be rather
  4. easy.  The problem was the hand-shaking necessary to keep the game(s) in sync
  5. on each machine.
  6.  
  7. The first version sent the entire game when a two-player session was
  8. established.  Moves were then sent from that point.  The first version also
  9. had undo/redo capability so that a user could back up the game a bit, and then
  10. after reviewing a previous position, redo forward to the current position.  I
  11. sent these undo/redo events to the other player, as well as regular moves.
  12.  
  13. The reason that these undo/redo events were sent is so that the two games
  14. would always be in sync.  The problem was that, just as one player was moving
  15. a piece, the other player could undo a move.  These messages would cross each
  16. other in transmission, and when recieved, would be processed.  This could (and
  17. did) cause the two board positions to not be in sync.  Obviously, some form of
  18. hand-shaking was necessary.
  19.  
  20. What I chose to do was to always transmit the entire game.  In sending a new
  21. game, I could then use a scrollbar to view previous positions.  By sending
  22. the entire game, I gained random access to any position in the game.
  23.  
  24. Of course, once I added the slider (custom scrollbar), then there was the
  25. problem that both players could be scrolling at the same time.  Each machine
  26. would be sending lots of AppleEvents, and neither one would be paying
  27. attention to them.  They would just queue up, and when the scrollbars were
  28. finally released, the board position events would be processed.  This
  29. processing of lots of queued events would cause the board to jump from one
  30. position to another, and then finally settle down when all the events were
  31. received and handled.
  32.  
  33. This simultaneous scrolling also caused the board positions to be out of sync.
  34. That's when I decided that I needed a creator of the game.  (The creator
  35. machine is the machine that initiated the game.)  The creator echos changes
  36. back to the other player.  This would guarantee that if the two board
  37. positions got out of sync, that they would get synced up again.  There is no
  38. way to prevent them from getting out of sync, since the users can be scrolling
  39. at each end at the same time.
  40.  
  41. This echoing by the creator solved a lot of problems.  For example:  There is
  42. a resign button that you can push if you wish to throw in the towel.  It is
  43. possible that both users could do this at the same time.  A resign message is
  44. sent to the other machine.  Both players get the message that the opponent
  45. resigned.  So, who won?  The creator machine echos what it received, which
  46. may change the state of the other machine.  This echoing of resignation
  47. messages guarantees that only one player can resign.
  48.  
  49. This should help you understand why I am sending the kind of events that I
  50. am, and some of the decisions that I made as to how to do stuff.  The rest
  51. of the application is rather straightforward application stuff, although
  52. there is a lot of code.  I think (hope) that there are enough comments in
  53. the code to explain everything.
  54.  
  55.  
  56. Eric Soldan
  57.